home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2123 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.6 KB  |  91 lines
  1. Newsgroups: hku.open-forum,hku.cc.forum,hk.comp.pc,comp.lang.c++,comp.lang.pascal.misc
  2. Path: hkusuc.hku.hk!pc
  3. From: kong@hkusua.hku.hk (someone)
  4. Subject: Re: Is Pascal worth to learn? Can it help me to get a job?
  5. X-Nntp-Posting-Host: 147.8.35.29
  6. Message-ID: <4devt9$844_001@news.hku.hk>
  7. Sender: usenet@hkusuc.hku.hk
  8. Organization: The University of Hong Kong
  9. X-Newsreader: News Xpress Version 1.0 Beta #4
  10. References: <30f2adf8.7810115@news.hku.hk> <DL2tFM.7DJ@hkuxb.hku.hk>
  11.     <4dcrl0$7mo_001@news.hku.hk> <SDLEE.96Jan15161338@champion.cs.hku.hk>
  12. Date: Tue, 16 Jan 1996 01:44:09 GMT
  13.  
  14. In article <SDLEE.96Jan15161338@champion.cs.hku.hk>,
  15.    sdlee@cs.hku.hk (Lee Sau Dan ~{@nJX6X~}) wrote:
  16.  
  17. >
  18. >    >>    For example, in C I can swap two integers a and b without
  19. >    >> using a temporary variable in three statements: a ^= b; b ^= a;
  20. >    >> a^= b , I can also use bit-vectors.
  21. >
  22. >This method of swapping is not as easy to understand as the method of
  23. >using a temp. variable.  Moreover, bit-vectors are for memory
  24. >optimization (and, to a certain extent speed optimization).  They are
  25. >difficult to debug and maintain and do not generalize to other
  26. >problems.  (E.g. when you swap to strings, you cannot use your proposed
  27. >method.)  This is not a good programming practice.
  28.  
  29. I do agree using the swapping method I mentioned is not a common practice 
  30. (and I myself never have to do it). But it does demonstrate the power of
  31. a language.
  32.  
  33. Bit-vectors ARE required in many cases, and I strongly disagree that they
  34. are difficult to debug or maintain. There are cases when there will be
  35. matrixes with hundreds or at times millions of elements, each containing just
  36. a few boolean values. It will be much easier to debug and maintain the code
  37. by using bit-vectors and use masks defined as constants to set or get the 
  38. required bits. Not to mention the memories saved compared to using arrays
  39. of booleans.   
  40.  
  41. >
  42. >So, to a beginner, these limitations are advantageous.  They train
  43. >a programmer to write more structurally and maintainably.
  44. >
  45. >
  46. >    >>    I can have generic pointers that may point to everything or
  47. >    >> nothing.
  48. >
  49. >Well... when you use such pointers, bear in mind the potential problems
  50. >and bugs that may result.  Such pointers bypasses the strong type-checking
  51. >mechanism of the language.  Think twice and before using such pointers.
  52. >They are often better ways to do the same thing.
  53.  
  54. Er.. right. While I said that in my post I was responding to the original
  55. poster's claim that Pascal can do everything other language can do. The
  56. ability to cast a pointer to something else is a two side sword. A good
  57. programmer can make use of it wisely. Lousy programmers make pointer
  58. errors out of it. (This is one reason why there is no pointer in Java.)
  59. However I do wonder there are cases generic pointers help a lot. That's why 
  60. you say "often" instead of "always".
  61.  
  62.  
  63. >
  64. >
  65. >    >> I can have arrays with no compile-time defined sizes.
  66. >
  67. >Beware of out-of-bound array references, then!  BTW, does C support
  68. >multi-dimensional arrays cleanly so that they can be passed into
  69. >procedures?
  70. >
  71.  
  72. Out-of-bound array references can happen in Pascal, if you turn-off
  73. your run-time array bound checking. Again, pointers arithmetic in
  74. C is a two side sword. 
  75.  
  76. >
  77. >    >> AFAIK there are no way of doing such things in Pascal. At least
  78. >    >> not in standard Pascal. There are also many fallbacks in Pascal
  79. >    >> that are inconvenient for programmers,
  80. >
  81. >Well... They are not always inconvenient for programers.  Very often,
  82. >they help to prevent bugs early.  
  83. >
  84. >
  85. >    >> e.g. no break within loops.  That's why there are things like
  86. >    >> Modula-2.
  87. >
  88.  
  89.  
  90. -- All opinions are mine, they do not reflect standings of my employer.
  91.